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METHOD FOR USING AUTOMATED TELLER MACHINE SWITCH 
SETTLEMENT FOR PROCESSING TRANSACTIONS 



10 

RELATED APPLICATION 

This application is based on and claims priority to U.S. 
Provisional Patent Applications Nos. 60/132,305, filed May 3, 1999, 
60/150,725, filed August 25, 1999, and 60/161,300, filed October 26, 1999, 

1 5 the entire disclosures of which are hereby incorporated by reference. 

FIELD OF THE INVENTION 

The present invention generally relates to methods for 
processing electronic payments purchases made over the Internet and more 

2 0 particularly to a method by which a consumer pushes a payment to an Internet 

merchant. 

BACKGROUND OF THE INVENTION 

Presently, there are several methods by which a consumer can 

2 5 electronically pay for purchases made on the Internet, such as credit cards, off- 

line debit cards, online debit cards, digital cash, and smart cards. Each of 
these methods has its own advantages and disadvantages. An off-line debit 
card uses the traditional credit card system for clearing the payment but no 
Personal Identification Number (PIN) is required. The use of an on-line debit 

3 o card requires that the consumer supply his or her PIN, and the amount of the 

purchase is debited from the consumer's account instantaneously. One 
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disadvantage with both the on and off-line debit cards, from a consumer's 
point of view, is the inability to reverse or repudiate the transaction. In 
contrast, by use of a credit card, the consumer at a later date can reverse the 
transaction (e.g., if the purchased goods are never shipped to the consumer). 
5 It is predicted that credit cards will be the dominant on-line point 

of sale (POS) payment choice, for at least the next five years. While new 
Internet payment mechanisms have been rapidly emerging, consumers and 
merchants have been happily conducting a growing volume of commerce 
using basic credit card functionality. None of the emerging efforts to date 

10 have gotten more than a toehold in the market place and momentum continues 

to build in favor of credit cards. 

Automated Clearing House (ACH) payments have begun to be 
used with respect to payments made via the Internet. These types of 
transactions typically involve payments made with respect to loans, insurance 

1 5 and utilities. It is predicted that ACH payments will not be widely deployed to 

on-line POS for two reasons. First, an ACH transaction does not provide 
transaction authorization, and secondly, authentication requires a pre-existing 
relationship between the customer and the merchant. Furthermore, ACH 
payments have to be received, deposited and cleared before the funds are 

2 0 available. In contrast to ACH transactions, credit and off-line debit cards 

require authorization but not authentication. Similarly, on-line debit requires 
authentication (i.e., a PIN or other authentication). 

Two significant drawbacks with some or all of the above models 
for Internet POS payments are that: 

25 1 ) a pre-existing relationship between the consumer and the merchant must 

exist; and 2) the consumer is required to provide the merchant with his or her 
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account and/or PIN. The first drawback of some of the above models cannot 
be practically overcome as it is impossible for a consumer to have pre-existing 
relationships with all of the potential merchants conducting business on the 
Internet. With respect to the provision of the consumer's account and PIN 
5 number over the Internet, even though mail order companies have been 

operating in this manner for years, many consumers feel uneasy about 
electronically providing their account and PIN numbers to strangers over the 
Internet. 

Figure 1 depicts the conventional debit/credit transaction model. 

10 In this model, if the consumer 100 desires to buy a compact disc (CD) from a 

web retailer 100, the consumer 100 electronically transmits its debit or credit 
card number and/or PIN to the web retailer 1 10. Upon receipt of this 
information from the consumer 100, the retailer 1 10 submits the proposed 
transaction to its bank 120 for approval. The merchant's bank 120 then 

15 contacts the bank 130 (issuer bank) which issued the debit/credit card to the 

consumer 100. The issuer 130 checks the consumer's balance on the card and 
either approves or rejects the proposed transaction. This approval or denial is 
■ transmitted from the issuer bank 130 back to the merchant bank 120 which 
then informs the web retailer 1 10 of the approval or denial. If the charge to 

2 0 the debit/credit card was approved, the transaction is completed by the web 

retailer 110 shipping the goods to the consumer 100. 

The at least one of the drawbacks described above equally 
applies to electronic bill payment. The first drawback, requiring a pre-existing 
relationship between the consumer and bill payee is not as great a concern 

2 5 because this relationship most likely already exists between the consumer and 

the payee (e.g., the telephone, cable or utility company for example). The 
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second drawback which requires the consumer to provide the payee with his or 
her account and/or PIN still remains a concern with electronic bill payment. 
Although fraud is less of a problem with respect to bill payment, since the 
consumer presumably has regular dealings with the payee, some consumers 
still view the provision of the payee with at least his/her account number a 
diminution in the consumer's privacy. 

SUMMARY OF THE INVENTION 

In the method of the present invention, a consumer uses its 
Internet software to browse the Internet for goods being offered by various 
Internet merchants. Once the customer finds an item its wishes to purchase, 
the consumer's Internet software extracts from the merchant's web site a price 
quote for the proposed purchase along with an identification of the merchant's 
bank and account number. The customer then transmits a payment request 
message to its own bank over the Internet. This payment request message 
simultaneously requests that the consumer's account be debited for the amount 
of the price quote and that the payment be made crediting the merchant's 
account at the merchant's bank. If there is sufficient funds in the consumer's 
account, the consumer's bank will return a payment advice digitally over the 
Internet which guarantees the payment. This payment advice is then 
transmitted by the customer's Internet software to the merchant's Internet 
server. With guaranteed funding, the merchant can immediately deliver the 
goods of services to the consumer. In an alternative embodiment, the payment 
advice is transmitted via the Internet directly from the consumer's bank to the 
merchant's Internet server. 
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Payment totals for each merchant are settled on a daily basis 
using Electronic Funds Transfer via the regional ATM network infrastructure 
with funds being moved from the consumer's account at its bank to the 
merchant's account at its bank. 
5 By the method of the present invention, both of the significant 

disadvantages of the prior art have been overcome. First of all, the consumer 
is no longer providing its confidential financial information to strangers over 
the Internet. Rather, the consumer is dealing directly with its own trusted 
institution, the bank. Furthermore, no pre-existing relationship has to exist 

1 o between the customer and the merchant. The only requirement is that the 

merchant recognize and honor the guaranteed payment from the consumer's 
bank. 

The present invention significantly reduces the transactional cost 
as compared to the use of credit cards. The method also provides a reduction 
15 in fraud and credit losses, while the finality of the transaction virtually 

eliminates dispute and chargeback processing from the viewpoint of the 
financial institution. 

The present invention is not limited to the case of a consumer 
making purchases from Internet merchants. The method has further, broader 

2 o applicability by providing the ability for anyone with an account at a financial 

institution to transfer funds to anyone else who also has an account at the same 
or a different financial institution. 

BRIEF DESCRIPTION OF THE DRAWINGS 
2 5 For the purposes of illustrating the present invention, there is 

shown in the drawings a form which is presently preferred, it being understood 
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however, that the invention is not limited to the precise form shown by the 
drawing in which: 

Figure 1 illustrates the prior art method of Internet payment 
processing using debit and/or credit cards; 
5 Figure 2 depicts a first embodiment of the method of the present 

invention; 

Figure 3 depicts a second embodiment according to the method 
of the present invention; 

Figure 4 illustrates a third embodiment of the method of the 
10 present invention; 

Figure 5 illustrates additional details of the method of the present 

invention; 

Figure 6 illustrates a specific example of the method of Figure. 

4; 

15 Figure 7 illustrates an Internet shopping model according to the 

present invention; 

Figure 8 illustrates a pay anyone model of the present invention; 
Figure 9 illustrates a wire anyone model of the present invention; 
Figure 10 illustrates a bill payment, direct model of the present 

20 invention; 

Figure 1 1 illustrates a bill payment, service provider 
consolidation model of the present invention; 

Figure 12 illustrates a bill payment, customer consolidation 
model of the present invention; and 
2 5 Figure 1 3 illustrates a structure and process for funding an 

Internet payment account wallet. 
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DETAILED DESCRIPTION OF THE INVENTION 

In contrast to the credit card, on-line and off-line debit and other 
payment models existing today, one of the unique features of the method of 
the present invention is the flow of the payment instruction and the payment 
which follows. In the credit card, on-line and off-line debit models, a 
consumer provides the merchant with an instruction that authorizes the 
merchant to collect funds from the consumer's bank account. Depending on 
the system, this payment instruction results in a guaranteed customer payment 
in the case of an on-line debit rather than a lengthy wait for funds (such in the 
case of a check) or something in between in the case of an off-line debit and 
credit card. The difference between the prior art models and the model of the 
present invention can be described as the difference between a "pull" and a 
"push" model. In the conventional models of today, the merchant "pulls" the 
payment from the consumer's account, while in the present invention the 
customer "pushes" the payment to the merchant's account. 

Figure 2 illustrates a first embodiment of the method of the 
present invention. Prior to conducting any on-line purchases using the method 
of the present invention, the consumer establishes an Internet payment account 
(IP A) 230 with its bank 220. Once this IP A account 230 has been established, 
the consumer funds this account from its demand deposit account (DDA) 240. 
The establishment of a separate IPA 230 is preferable from a consumer's point 
of view in order to provide a separate accounting and statement from its 
normal DDA account 240. Furthermore, the IPA account might not be interest 
bearing and the consumer would accordingly only fund small amounts into 
this account in order to cover potential on-line purchases. In an alternative 
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embodiment of the present invention, the consumer's payment request for 
credits and debits can be made directly against its DDA account 240. 
Furthermore, the IPA 230 can be funded from a consumer's Line of Credit or 
credit or debit card account held by the bank 220 or any other linked account 
from which the consumer can transfer funds. 

The consumer uses Internet browsing software 200 in order to 
initiate a payment transaction. In one embodiment of the present invention, 
the Internet software is loaded on the consumer's personal computer 201 . In 
alternative embodiments, the software can reside in a web enabled ATM 
machine 202, or remotely located and accessed via a telephone 203. The 
element Other 204 has been illustrated in order to convey that the present 
invention is not limited by any particular physical device and can employ any 
device which provides access to the Internet. For example a public Internet 
kiosk which provides access to the Internet can be used to practice the present 
invention. 

In one embodiment of the present invention, the Internet 
software 200 is used in order to browse the Internet and visit the web sites of 
various merchants. As a consumer browses the web site of a particular 
merchant 210, all of the information viewed by the consumer is downloaded 
onto the consumer's computer or the device which is providing the Internet 
access. This downloaded information includes prices for the goods and 
services offered by the merchant as well as an identification of the merchant's 
bank 250 and the number of an account 260 which the merchant holds at its 
bank 250. If a consumer decides to go ahead with a particular purchase, the 
consumer's Internet software 200 extracts from the downloaded information 
the price for the item and the identification of the merchant's bank 250 and 
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account number 260. A transaction identifier is preferably assigned at this 
time either by the merchant's Internet server 210 or the consumer's software 
200. 

In another embodiment of the present invention, the entity who 

5 will eventually be receiving funds from the consumer can be an individual. 

For example, the consumer might be responding to a classified advertisement 
(electronic or traditional paper) or purchasing an item or a service through an 
electronic auction site such as eBay(TM). In either of these cases, the 
consumer obtains the payee's bank 250 identification and account number 260 

10 in a variety of ways. In one method, the consumer obtains this information 

electronically from the service where it contacted the individual (e.g. through 
eBay(TM)). Alternatively, the consumer can obtain the necessary destination 
bank information through offline methods such as the traditional paper 
classified advertisement or through an Email which has been "pushed" to the 

1 5 consumer by the potential payee. 

In an alternative bill paying embodiment, the consumer has all of 
the relevant bank and account information for each of the payees (e.g. 
telephone service provider) which the consumer regularly pays bill 
electronically. An electronic bill can be presented to the consumer either 

2 o through E-mail or from an Internet site maintained by the payee or by a 

Consumer Service Provider for the payee. The bill can contain a button for 
paying the bill through the use of the present invention (i.e. through the ATM 
system). When the customer selects the button, a template is presented to the 
customer which has all of the bank and account information prefilled. The 

2 5 customer merely fills in the amount he/she wishes to pay. Upon completion, 

the user selects a transmit button in response to which the payment message is 
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formatted with the supplied information and transmitted to the consumer's 
bank for processing. The same payment template can be used either included 
in an E-mail or from the payee's web site as described above. 

In a further embodiment, the consumer has a personal 
relationship with the eventual payee and has been previously provided with the 
destination banking information by the eventual payee. For example, if a 
parent has a son or daughter away at college, the parent has knowledge of the 
child's bank 250 and account 260 and is able to transfer funds to the child's 
account 260 in a simple, quick and cost efficient manner by use of the present 
invention. 

Returning to Fig. 2, with the bank 250 identification and account 
260 information in hand, the consumer's Internet software 200 formats and 
transmits a message containing this information to its own bank 220. The 
message will contain at least the identification of the consumer's account 230, 
the destination bank 250, and the destination account 260. For example, this 
payment instruction from the consumer asks that fifty dollars be debited 
against its account #1234 and that credit be forwarded to merchant's account 
#5678 at the merchant's bank. 

With respect to authentication, because the consumer is pushing 
the payment to merchants or other entities or individuals, rather than the 
merchants pulling payments from consumer accounts, the consumers do not 
need to authenticate themselves to the merchant. Rather, the consumers 
authenticate themselves to their own bank 220 which then executes the 
payment to the merchant's account. The consumer's bank 220 will require 
some form of authentication of the payment request from the consumer. This 
authentication can be in the form of a software certification, an encrypted PIN, 
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or the mother's maiden name of the consumer. Once the bank 220 has 
authenticated that the message truly originated from the consumer, the bank 
220 can then fulfill the payment request. 

This method of the present invention is quite attractive to 
consumers because they can pay any individual or entity regardless of the 
existence of a pre-existing relationship with that individual or entity. The 
transaction can furthermore be conducted from anywhere there is access to the 
Internet. The IPA account 230 can be used and managed through the 
consumer's PC 201 , a web enabled ATM 202, by phone 203 or by any other 
web enabled device 204. With respect to merchants, individuals or other 
entities which are paid by the method of the present invention, there are 
several advantages. This method opens up a universe of buyers/payors 
without the access or desire to use credit or debit cards online. A very low 
effort is required on the part of a merchant which only has to publish its bank 
250 and IPA deposit only account 260 information on its web site. If a 
merchant has been using traditional credit card methods, the present invention 
provides the merchant with significant savings in credit card processing, fraud 
loss, and chargeback costs. The present invention also provides the ability to 
economically accept micropayments. 

Returning again to Fig. 2, in fulfilling the payment request from 
the consumer, the bank 220 will initially verify that there are sufficient funds 
in the consumer's IPA account 230 to satisfy the payment request. If there are 
sufficient funds in the consumer's IPA account 230, the account is 
immediately debited or the funds held such that funds equal to the amount of 
the payment are no longer available in the customer's IPA account 230. The 
funds debited from the consumer's IPA account 230 are credited to the 
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destination account 260 as described in more detail below. If insufficient 
funds exist in the customer's IPA account 230, the payment request is denied 
and the consumer's Internet software 200 is informed of the insufficient funds 
condition. In an alternative embodiment of the present invention, the 
consumer is provided with the ability to transfer funds from its DDA account 
240 into the IPA account 230 such that sufficient funds are available to cover 
the payment request. 

If sufficient funds exist in the IPA account 230 to process the 
payment request, the consumer's bank 220 generates a digital payment advice 
which is transferred back over the Internet to the consumer's Internet software 
200. In a preferred embodiment, this payment advice is digitally signed by the 
consumer's bank 220, thus guaranteeing the payment. Once this payment has 
been digitally signed by the consumer's bank 220, all of the risk associated 
with this payment lies with the consumer's bank 220 and not with the merchant 
210 or its bank 250 as with some of the models described above. For this 
reason, the model of the present invention is an attractive alternative to 
merchants conducting business on the Internet. Various forms of 
implementing the digital signature by the consumer's bank 220 are well known 
in the art. 

Upon receipt of the payment advice from the consumer's bank 
220, the consumer's Internet software 200 forwards this payment advice to the 
merchant's Internet server 210. Once the merchant has received the payment 
advice from the consumer's Internet software 220, the transaction can be 
completed by the shipment of the goods or provision of the service to the 
consumer. 
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The settlement process between the consumer's bank 220 and the 
merchant's bank 250 typically occurs once, a day, at the end of the day, but 
may occur in real time or batched processed when the transactions reaches a 
dollar or absolute number limit. As described above, the consumer's IPA 
5 account 230 has been debited for the amount of the purchase. This debited 

amount now needs to be transferred to the merchant's bank 250 in order that a 
credit be applied to the merchant's account 260. In a preferred embodiment of 
"the present invention, the merchant has established a deposit only IPA 260 in 
which funds can only be deposited and not withdrawn. This is a security 

1 o feature which protects the merchant from various forms of electronic fraud. 

Alternatively, the destination account 260 could be another type of deposit 
only account or a DDA account in the case where the receiving party truly 
trusts the consumer (e.g. the parent/child relationship previously described). 

In the present invention, the. consumer's bank 220 accomplishes 
1 5 the payment settlement via the conventional ATM electronic Funds Transfer 

process. Using this well known process, the consumer's bank 220 designates 
the merchant's bank 250 and the specific account 260 to which the credit of the 
purchased amount should be applied. Furthermore, the consumer's bank can 
include in the ATM message the transaction ID previously described for 

2 0 tracking and auditing purposes by the merchant and the merchant's bank 250. 

This auditing information allows the merchant to match the merchant's 
payables to its receipts. This information can also be used in the reconciliation 
process with respect to the merchant's account. 

Periodically, funds from the merchant's deposit only IPA 
2 5 account 260 are transferred (swept) by the merchant bank 250 into the 

merchant's conventional DDA account 270. 
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Figure 3 illustrates an alternative embodiment of the present 
invention. All of the initial steps with respect to the consumer browsing the 
merchant's web site and formulating the payment request which is forwarded 
to its bank 220 are the same as illustrated in Figure 2. The difference in the 
embodiment illustrated in Figure 3 as compared with the embodiment depicted 
in Figure 2 is that the payment advice from the consumer's bank 220 is 
forwarded directiy to the merchant's Internet server 210. This payment advice 
will therefore come from a separate Internet Protocol (IP) address from the 
address that connects the consumer's Internet software 200 to the merchant's 
Internet server 210. This feature will provide additional confidence to the 
merchant that the advice has indeed originated from the consumer's bank and 
is not a fraudulently generate advice. 

The push model of the present invention has significant 
advantages over the conventional methods used today. This method is 
extremely easy for online banking customers to adopt. The method guarantees 
payment to the merchant without any concerns about repudiation inherent in 
the use of a credit card. The present invention reduces fraud loses compared 
to offline debit, credit card or checks. The method allows consumers to 
conduct online shopping without having to provide any personal confidential 
financial information to unknown merchants. The method allows consumers 
to conduct these financial transactions solely with its own financial institution. 

Fig. 4 illustrates the broader embodiment of the present 
invention briefly described above. In this embodiment, a customer 1 (payor) 
of a financial institution is able to transfer funds to a customer 2 (payee) of a 
the same or different financial institution. This embodiment is particularly 
suitable for the bill payment example described above. Prior to the practice of 
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the method illustrated in Fig. 4, both customer 1 (payor) and customer 2 
(payee), must each have established an account and deposited funds into their 
respective financial institutions. In a preferred embodiment, these accounts 
are specific Internet Payment Accounts (IPA) II and 12, at the customers' 
5 respective banks Bl and B2 (Fig. 5). Here, customer 1 has deposited $1000 

into IPA II and customer 2 has deposited $200 into IPA 12. As previously 
described, an IPA can be funded through any linked account such as the 
customer's DDA or credit account, or through another IPA. The customer 
does not need to have a DDA or credit account at a bank to set up an IPA, as 

1 o these accounts could be funded by accounts at another bank or through cash. 

As shown in Fig. 5, however, both customer 1 and customer 2 have linked 
DDA accounts Dl and D2, respectively, to IPA II and IPA 12. Once this is 
done, the IP As can be used for web shopping, pay anyone anywhere, and bill 
payment. Alternatively, as described above, the payments made according to 
15 the method of the present invention can be made directly from/to a DDA 

account. 

Once customer 1 has set up its IPA II , the customer 1 can 
request that payments be made (e.g. bills) through the IPA II. With this 
payment system, customer 2, the payment recipient, can be a billing company, 
20 such as a telephone company. As previously described with respect to Fig. 3, 

in step 400, the payment can be requested by phone, ATM or PC. Customer 1 
must give his/her bank, Bl, the following information: the payment amount, 
customer 2's BIN and IPA#. In step 410, this information is used by bank Bl 
to create a transaction instruction filed under a transaction ID#, Tl. Because 

2 5 customer 1 is directly contacting his/her own bank Bl, no authorization is 

required. Customer 1 authenticates him/herself by inputting a pin number or 
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other ID. In step 420, after authentication, customer l f s bank, Bl, debits 
customer l's IPA, II, by the amount of the payment (e.g. $100 as illustrated in 
Fig. 4). In step 430, the transaction instruction representing the credit to 
customer 2 is transmitted to customer 2's bank B2 through the ATM network. 
The receiving bank B2 can send a confirmation message back to customer 1 
through its bank Bl that the transaction was received by bank B2. 

In step 440, upon its receipt by the bank B2, the transaction 
information Tl representing the credit to customer 2 ! s account, is stored in a 
personal virtual lockbox. Alternatively, the credit is directly applied to 
customer 2 r s IPA 12. The concept of a personal virtual lockbox is borrowed 
from retail lockbox processing in which a bank collects the receivables for an 
entity and performs the financial processing on such receivables. The personal 
virtual lockbox in the present invention operates similarly in that it stores 
receivables throughout the day for customer 2 which are then swept, in step 
450, into the customers IPA 12. In step 460 the actual credit is applied to 
customer 2's IPA 12. 

Reference is now made to Fig. 6 which illustrates a further 
example of the present invention. Fig. 6 illustrates a specific application of the 
present invention in which a customer 1 desires to transfer funds to customer 
2, where customer 2 is anyone that needs to be paid, such as one's gardener, or 
anyone who requires funds, such as a child at college. As with the example of 
Fig. 4, customer 1 and customer 2 preferably have established and deposited 
funds into Internet payment accounts IPA II and IPA 12 at the customer's 
respective banks Bl and B2 (Fig. 5). Customer 1, for example the owner of 
real property, has deposited $1000 into IPA II and customer 2, for example a 
gardener, has deposited $200 into IPA 12. 
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Although not necessary, customer 1 and customer 2 have 
established DDA accounts Dl, D2, respectively, at their banks Bl, B2 to link 
with the IPA accounts. 

At step 600, customer 1 requests that a payment be made, for 
example by phone, ATM, PC, etc. In this instance, customer 1 wishes to 
transfer $100 from his IPA account II in bank Bl to customer 2*s IPA account 
12 at bank B2. At step 610, customer 1 provides his payment account number, 
customer 2's BIN number and customer 2's IPA account number. This 
produces a transaction instruction for a particular transaction, here designated 
ID# 1, where the BIN number is designated B2 and the IPA number is 
designated 12. Customer 1 authenticates himself by inputting a pin number or 
other such ID number into the system. 

At step 620, bank Bl debits customer l's IPA II by $100, 
leaving IPA II with a balance of $900. At step 630, the transaction instruction 
is transmitted to bank B2 through the ATM switch network. 

At step 640, the transaction instruction commanding a deposit 
into customer 2's IPA account 12 is stored in a personal virtual lockbox. As 
previously discussed, the credit to customer 2's IPA account 12 may 
alternatively be directly applied rather than utilizing the virtual lockbox. The 
credit of $100 is applied to customer 2*s IPA 12 when accounts are swept in. 
At step 650, customer 2 actually receives the $100 credit to his account and is 
provided with a bill payment message indicating that the transaction was 
completed. 

Those skilled in the art will appreciate that the above example 
applies equally well to the situation in which customer 1 would wish to 
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transfer funds to, for example, a child at college, rather than providing funds in 
exchange for services. 

The following sections will describe six different specific 
embodiments of the present invention with respect to Figures 7-13. The Global 
5 Electronic Payment Solution represents a new payments paradigm that 

leverages legacy platforms, conventional payments infrastructure and currently 
available web-based technology to enable e-commerce in both the virtual and 
physical marketplace. The concept provides a safe, sound, and secure method 
that will allow consumers to shop on the web, pay bills, and pay anyone 

10 virtually anywhere. . . all without the consumer having to share account 

t number information with the payee. Merchants will get immediate payment 
confirmation through the EFT networks so they can ship their product with 
confidence. This concept also enables small dollar financial transactions, 
allows for the creation of "web cash" as well as provides customer service and 

15 record-keeping. 

We intend to offer this concept as a value-added service to 
Chase customers, and license it to the nation's banks for distribution to their 
corporate and retail customers. By connecting consumers 5 digital wallets to 
the merchants' Virtual Private Lockboxes through the EFT networks, the 

2 0 nation's banks can maintain their dominance in the payments mechanism. 

How it Works - The enabling functionality resides in four pieces: 
a "Wallet", a "Virtual Private Lockbox/VPL Reporter", an "Internet Pay 
Anyone (IPA) Account" and the Nation's EFT networks. The Wallet is a 
software application that augments any Internet browser with e-commerce 

2 5 capability. The software sits in front of (and links to) either a DD A account or 

an IPA account. The IPA account is a special purpose DDA with limited 

00427400.1 



- 19- 



functionality,. similar to EZ-Pass or Ready Pay. Once a transaction is 
authorized on the web, the payment is then passed through the existing ATM 
infrastructure. 

The Wallet - The Wallet is a secure portal for accessing your 
5 DDA or IPA account. It can be purchased on line and is activated through any 

Internet browser. Consumers use this Wallet to fond their account, shop on 
the web, fill out web purchase forms automatically, pay bills, pay anyone, 
store electronic receipts and check their recent Wallet activity. The Wallet 
provides consumers with a safe, secure, and convenient way to conduct 

1 o financial transactions over the web. 

The Virtual Private Lockbox (VPL) - The VPL is a limited 
function DDA account. A VPL is constructed with the ability to receive any 
electronic payment. It can only send funds to its corresponding DDA or IPA 
account. Therefore a VPL is a secure address that can be provided to the 
1 5 public as a means of receiving funds. Additionally, since it will receive 

transaction data from the EFT network, it will provide immediate notification 
of incoming payments. 

Internet Pay Anyone Account (IPA)- IPA's are DDA accounts 
with limited functionality similar to EZ-Pass and Ready Pay. Funds can be 

2 o accessed electronically through a PC or via card reader technology only. This 

restriction enables sale of this product to markets where banks do not have 
brick and mortar and enables controlled or restricted purchase ability and 
funds distribution (e.g. enables parental control). 

The VPL Reporter- Similar to a consumer Wallet, the VPL 
2 5 Reporter is a portal to your VPL account via the Internet. However, the 

functionality of a VPL Reporter differs greatly from a Wallet. The VPL 
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Reporter is a merchant tool that provides online, real-time transaction reports, 
and reconciles accounts receivable/purchase records against incoming EFT 
payment records. In addition, transaction history can be archived and 
retrieved via the VPL Reporter's payment search engine, so that merchants can 
have powerful data mining and customer service tools at their fingertips. 

With reference to Figure 7, Web Shopping: The Wallet and the 
Virtual Private Lockbox (VPL) significantly enhances the consumer and 
merchant experience when used for web shopping. A Wallet icon will be 
located on the browser toolbar. When shopping the web, the user simply 
launches the Wallet. Once the consumer commits to purchasing an item, the 
merchant's site will recognize that the transaction is from a Wallet owner. The 
Wallet will instantly fill out all required fields. In addition, rather than the 
merchant "pulling" in the consumers account information, the Wallet "pushes" 
guaranteed funds to the merchant's Virtual Private Lockbox, without the 
merchant obtaining the consumers account info. This transaction is virtually 
instantaneous, provides privacy, security, and convenience to the consumer - 
and guarantees funding, provides reconcilement, and supplies archival records 
to the merchant. The following further describes the enumerated steps 
illustrated in Figure 7. 



Step# 


Description 


1 


User launches browser, goes web shopping. After 
electing to make a purchase selects Wallet icon from 
browser toolbar. 


2 


User keys in user ID and password. The user is 
authenticated and has access to their Wallet. 
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User is then presented with balance information and can 
select from several options: 




• ^Virvn nn thp Wph 

• Pay Anyone 

• Pay Bills 


4 


User selects "Shop on the Web". Browser could be 

approved merchants, however user is free to navigate to 
the merchant web site of their choice. 


5 


User selects item for purchase from merchant web site. 
Since web Wallet is active, merchant recognizes user as a 
Wallet customer, and purchase fields (shipping address, 

IlalllCj Civ. ) alC aUlU pupuiaLCU llUlll yv aii^u 


6 


Merchant site generates and transmits to user a bill 
payment message providing the following data: 
iviercnani dun 
- Merchant Account # 

• Transaction ID 

* $ Amount 


7 


Bill Payment message is transmitted back to Wallet 
window. User reviews bill payment message and selects 
"purchase item". 


8 


Wallet verifies balance and passes transaction to IPA or 
DDA account; payment conformation sent to the 
Merchant's website. 


9 


Bill payment message is passed from user's bank's IPA or 
DDA to the merchant's VPL via the ATM switch. 


10 


The bill payment record is transmitted from the 
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merchant's VPL to the merchant's VPL reporter. 


11 


Upon receipt of the payment message, merchant's 
payment record can be reconciled against the merchant's 
purchase records. With VPL reporter, Merchant has a 
product that allows for secure transaction fulfillment, 
reconcilement ability, record-keeping and archive 
possibilities. 


12 


Merchant ships goods 


13 


Funds are settled once a day between user's bank's DDA 
and merchant's bank's DDA. 


14 


Funds can be swept to merchant's cash concentration 
bank. 



15 Referring now to Figure 8, Model #2A, Pay Anyone: The Wallet 

provides the user with tremendous flexibility. Anyone with a Wallet can send 
funds to anyone else with a Wallet. This funds transfer is instantaneous and at 
no cost to the consumer, and is conducted in a secure environment. The 
following further describes the enumerated steps illustrated in Figure 8. 

20 



Step# 


Description 


1 


User launches browser and selects Wallet icon from 
browser toolbar. 


2 


User keys in user id and password. The user is 
authenticated and has access to their Wallet. 


3 


User is then presented with balance information and can 
select from several options: 
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• Shop on the Web • Wire Anyone 

• Pay Anyone • Fund Wallet 

• Pav Bills • Check Receipts from Wallet Activity 


4 


User selects "Pay Anyone". User is given several options 
in the Pay Anyone menu screen: 

• Manually key in payee's VPL # 

• Select a prior payee from a drop down menu 

• Add/Remove/Edit Payee from drop down menu 

• Go to online directory of VPL #s 

User keys in (or selects) payee's VPL #, $ amount, and a 
description (optional). Please note: 5, 6 and 7 can be 
eliminated for redundant/repeating payments to known 
payees. 


5 


Payment info, is transmitted to payee's Wallet for VPL # 
verification as well authorization to pay. 


6 


VPL confirms that information is correct and transmits a 

noumAnt mPCCQffP With trlP fnlmWiriCT fmtfl* 

Day men I IllCooagC Willi llic lUliuwnig uaia. 

* Payee BIN 

* Payee Account # 

■ Transaction ID 

* $ Amount 

■ description 


7 


User reviews pavment message and selects u OK to Pay". 


8 


Wallet sends transaction to VPL account; an expected 
payment record is also transmitted to the payee's Wallet. 


9 


Payment message is passed from user's bank's IPA or 
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DDA to the payee's VPL via the ATM switch. 


10 


The payment record is transmitted from the payee's VPL 
to the payee's Wallet 


11 


Upon receipt of these guaranteed rands, payee's payment 
record is reconciled against the expected record. 


12 


Payee now has immediate use of rands. These funds can 
be used for web shopping, bill payment, pay anyone, or 

withdrawal via an ATM 


13 


Funds are settled once a day between user's bank's DDA 
and payee's bank's DDA. 


14 


Once a day, the VPL will sweep funds to its 
corresponding DDA or IPA. Those funds can then be 
accessed for ATM withdrawal. 



15 With reference to.Figure 9, Model #2B, Wire Anyone: Another useful 

feature of this model is the ability to wire anyone funds instantly. A wallet 
owner can set up an IPA account for anyone else, and then move funds to their 
account immediately. The transaction is conducted in a secure environment. 
The following further describes the enumerated steps illustrated in Figure 9. 
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Step# 


Description 


1 


User launches browser and selects Wallet icon from 
browser toolbar. 


2 


User keys in user id and password. The user is 
authenticated and has access to their Wallet. 


3 


User is then presented with balance information and can 
select from several options: 
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• Shop on the Web • Wire Anyone 




• Pay Anyone • Fund Wallet 




• Pay Bills • Check Receipts from Wallet 




Activity 


4 


User selects "Wire Anyone". User is given several options 




in the Wire Anyone menu screen: 




Does the payee already have a Wallet? 




Yes: (see pay anyone model 2 A) 




No: User is prompted with an account setup screen and 




asked "Would you like to buy a Wallet?" If Yes, user is 




1*11 

prompted to provide the following: 




Name of account owner 




Proposed Password 




User keys in requested info, the information is validated, 




and an IPA account is established. User then keys in the S 




amount to wire. 


5 


A Payment confirmation is generated with the following 




data: 




Payee BIN 




Payee IPA # 




Transaction ID 




S Amount 




The user selects "OK to Pay" 
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6 


Wallet sends transaction to payee's IPA account, and the 
account is now funded 


7 


The Payee can withdraw the funds via an ATM through 
the use of the IPA and PIN established by the Payor. 
When the withdrawal is requested, a payment message is 
transmitted from the Payor's IPA account to the ATM 
provider bank. 


8 


Payee now has immediate use of funds, and the 
withdrawal is made. 


9 


Funds are settled once a day between Payee's bank's 
DDA and the DDA of the ATM provider bank. 



Turning to Figure 10, Model #3 A - Bill Payment-Direct: There are 
three different bill payment methods described in this document. The first 
method is the direct model. In this model a biller establishes an e-billing 
capability on its own web site. Once enrolled in the service, the customer will 
receive an e-mail notification that a bill is available for payment at the biller's 
web site. The customer will launch the Wallet from the browser and then 
access the biller's web site. A payment will then be transmitted from the 
Wallet to the biller's Virtual Private Lockbox. As in the other models, the 
transaction is secure, protects the customer's privacy, and provides the biller 
with guaranteed funding, reconcilement, and archival records. The following 
further describes the enumerated steps illustrated in Figure 10. 



Step# 


Description 




Establishing e-billing relationship 
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1 


Merchant advertises e-billing service via e-mail, mail, or 
web. 


2 


User enrolls m e-bill service at buler s web site. Alter 
enrollment, user will receive monthly email notification 
when bills are available. 




Usine the Wallet 


3 


User launches browser and selects Wallet icon from 
browser toolbar. User keys m user id and password. I he 
user is authenticated and has access to their Wallet. 


4 


User is then presented with balance information and can 

select from several options: 
Shop on the Web 

Pay Anyone 

Pay Bills 




User selects "Pay Bills". User is given several options in 
the Pay Bills menu screen: 
Pay Bills 

Edit Billing information (i.e. name and address) 

User selects "pay bills" and navigates to biller's web site 
(Wallet will already contain user's billing info) 


5 


Since web Wallet is active, biller's website recognizes 
user as a Wallet customer. In addition, biller's website 
verifies that customer has an established e-billing 
relationship. 


6 


Biller site generates and transmits to user a bill payment 
message providing the following data: 
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Biller's BIN 
Biller's Account # 
Transaction ID 
$ Amount 


7 


Bill Payment message is transmitted back to Wallet 
window. User reviews bill payment message and selects 
"pay bill". 


8 


Wallet verifies balance and passes transaction to 
IPA/DDA account; payment conformation sent to the 
Biller's website. 


9 


Bill payment message is passed from user's bank's 
IPA/DDA to the biller's VPL via the ATM switch. 


10 


The bill payment record is transmitted from the biller's 
VPL to the biller's VPL reporter (virtual private lockbox 
reporter). 


1 I 


Upon receipt of these guaranteed funds, biller's payment 
record is reconciled against the biller's accounts 
receivable files. With VPL reporter, Merchant has a 
product that allows for secure transaction fulfilment, 
reconcilement ability, record-keeping and archive 
possibilities. 


12 


Funds are settled once a day between user's bank's DDA 
and biller's bank's DDA. 


13 


Funds can be swept to biller's DDA or cash concentration 
bank. 



With reference to Figure 11, Model #3B - Bill Payment- Service 
Provider Consolidation: The second bill payment method is similar to the 
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first, however in this model a central service provider consolidates e-bills from 
different billers, so that the customer has a single web site for reviewing bills 
and making payments. The service provider can be seamlessly outfitted with 
archival capability, so that customers can review their bill payment history. 
The Wallet provides the consumer with privacy, security and convenience. 
The Virtual Private Lockbox provides Merchants receiving payments through 
this web site guaranteed funding, reconcilement and archival records. The 
following further describes the enumerated steps illustrated in Figure 1 1 . 



Step# 


Description 




Establishing e-billing relationship 


1 


Customer Service Provider (CSP) advertises e-billing 
service via e-mail, mail, or web. 


2 


User enrolls in e-bill service at CSP's web site, and selects 
which bills it wishes to receive. After enrollment, user 
will receive monthly email notification when bills are 
available. 




Using the Wallet 


"! 
j 


User launches browser and selects Wallet icon from 
browser toolbar. User keys in user id and password. The 
user is authenticated and has access to their Wallet. 


4 


User is then presented with balance information and can 

select from several options: 
Shop on the Web 

Pay Anyone 

Pay Bills 
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User selects "Pay Bills". User is given several options in 
the Pay Bills menu screen: 
Pay Bills 

Edit Billing information (i.e. name and address) 
Review Billing History 
User selects "pay bills" and navigates to CSP's 


5 


Since web Wallet is active, CSP's website recognizes user 
as a Wallet customer. In addition, CSP's website verifies 
that customer has an established e-billing relationship. 


6 


User selects which bills to pay, and keys in $ amount. 

CSP site generates and transmits to user a bill payment 

message providing: 
CSP's BIN 

CSP's Account # 

Transaction ID 


7 


Bill Payment message is transmitted back to Wallet 
window. User reviews bill payment message and selects 
"pay bill". 


8 


Wallet verifies balance and passes transaction to 
IPA/DDA account; bill payment expected record is 
transmitted to the CSP's website. 


9 


Bill payment message is passed from user's bank's 
IPA/DDA to the CSP's VPL via the ATM switch. 


10 


The bill payment record is transmitted from the CSP's 
VPL (virtual private lockbox) to the CSP's VPL reporter. 


11 


Upon receipt of these guaranteed funds, CSP's payment 
record is reconciled against the CSP's accounts receivable 
file. With VPL reporter, Merchant has a product that 
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allows for secure transaction fulfillment, reconcilement 
abilitv, record-keeping and archive possibilities. 


12 


runds 316 settled once a Qdy uciweeii usci :> uaws. a i^^-n. 
and Cillers' bank's DDA. 


13 


Funds can be swept to billers' cash concentration bank. 


14 


Note: Multiple record keeping models can be supported. 
The billers can push billing info, directly to the CSP's 
web site, or alternatively, bills can be channeled to the 
CSP via Spectrum. 


15 


Note: CSP can be outfitted with an archive to store 
transaction history as well as a customer service unit to 
resolve transaction inquiries. 



With reference to Figure 12, Model #3C - Bill Payment- Customer 
Consolidation: In the third bill payment method, the e-bills are delivered 
directly to the customer in the form of an e-mail. Each e-bill contains a 
hotlink, which directs the customer to the biller's web site. When the customer 
activates the Wallet, the web site recognizes the Wallet customer and initiates 
a payment message. The customer can then push the payment to the biller in 
the same manner that a payment is pushed in the web model, pay anyone 
model, and two other bill models. As in the two previous models, the 
merchant receives the guaranteed funding, reconcilement, and archival records 
benefits of the Virtual Private Lockbox product. The following further 
describes the enumerated steps illustrated in Figure 12 



00427400.1 



-32- 



Step# 


Df^rnntinn 




Fstahhshino p-hillincr rp1atinn<shir> 


1 


Biller advertises e-billing service via e-mail, mail, or web. 


2 


User enrolls in e-bill service by clicking on "sign me up!" 
hotlink in email, which launches browser and auto-directs 
user to toiler's web site. After enrollment, user will 
receive bills directly in their email box. 




Using the Wallet 


3 


TT t i *1 1 * 1 *11 T T 1* 1 

User logs on to email and receives an e-bill. User clicks 
on payment hotlink in email, which launches browser and 
auto-directs user to billers web site. User selects Wallet 
icon from browser toolbar. User keys in user id and 
password. The user is authenticated and has access to their 
Wallet. 


4 


Since web Wallet is active, toiler's website recognizes 
user as a Wallet customer. In addition, biller's website 
verifies that customer has an established e-billing 
relationship. 


5 


User keys in S amount to pay. Biller's site generates and 

1 * i i 1*11 i *J"xl 

transmits to user a bill payment message providing the 
following data: 

Biller's BIN 

Biller's Account # 

Transaction ID 

$ Amount 


6 


Bill Payment message is transmitted back to Wallet 
window. User reviews bill payment message and selects 
"pay bill". 
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7 


Wallet verifies balance and passes transaction to 
IPA/DDA account; a bill payment expected record is 
transmitted to the Biller's website 


8 


Bill payment message is passed from user's bank's 
IPA/DDA to the biller's VPL via the ATM switch. 


9 


The bill payment record is transmitted from the biller's 
VPT to the hiller's VPL reDorter. 


10 


Upon receipt of these guaranteed funds, biller's payment 
rprnrH is reconciled aeainst the biller's accounts 
receivable file. With VPL reporter, Merchant has a 
product that allows tor secure transaction luinimicm, 
reconcilement ability, record-keeping and archive 
possibilities. 


11 


Funds are settled once a day between user's bank's DDA 
and billers' bank's DD A. 


12 


Funds can be swept to biller's cash concentration bank or 
DDA. 



With reference to Figure 13, Funding the Wallet - The Internet Pay 
Anyone (IPA) account is accessed through a virtual Wallet. This Wallet can 
be accessed via the Internet, ATM, telephone, Kiosk, and even a personal 
digital assistant. The primary method for funding the Wallet is through the 
Wallet owner's DDA, credit, and savings accounts, which can be linked to the 
Wallet through Online Banking. Alternative funding options are by an 
externally sponsored credit card, by check or money order, or through the 
ACH network. The following further describes the enumerated steps 
illustrated in Figure 13. 
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Step # 


Description 




Installing the Wallet 


1 


User goes to mybank.com via PC. 

User selects the Wallet option from main menu. There are 

two options: 

Are you an Online Banking customer? 

Are you a Non-Chase customer? 


2 


If user selects Online Banking customer, their Wallet will 
be linked to DDA account or IPA account. 
If user selects Non-Chase bank customer, the software 
will open a new IPA account and corresponding VPL 
account to enable Wallet functionality. 




Next the user sets up a web Wallet for use by choosing 
Install a Web Wallet from the menu. Screen instructs user 
that web Wallet will now be installed as a button on the 
browser toolbar. Once installed, user is prompted to 
provide some background information that will assist in 
web purchases and payments: examples include: shipping 
name, shipping address, and other optional information. 




Funding the Wallet 


4 


For the Chase customer, the primary method for initial 
and future funding of Wallet is performed through a link 
between the Wallet and Online Banking. For initial 
funding of the Wallet, the user will select "move funds 
to/from Wallet" from online banking menu. User selects 
"move funds to Wallet", and provides the following: 
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• Source of funds- checking, credit card, savings, etc. 

• S amount • funding date 

• one time or repeat 

Upon completion of above, the Wallet is funded 

(subsequent funding of the Wallet can be done via both 
the Wallet or directly within Online Banking). 


5 


In addition to funding via online banking, instructions can 
be given for funding via phone, ATM, kiosk, or PDA. 




Funding the Wallet from an external credit or debit card, 
or DD A account 


6 


For the Non-Chase customer or a Chase customer wishing 
to fund Wallet externally, user selects "fund with a non- 
[my bank] account". User selects the financial merchant 
(AMEX, VISA, or other bank DDA with debit card 
functionality) and keys in account number, expiration (if 
applic.), and $ amount, and a funding request is 
transmitted to merchant acquirer (this account info will be 
stored for future funding requests). 


7 


Merchant Acquirer (such as Chase Merchant Svcs) 
authorizes the transaction and passes the request through 
the EFT switch. 


8 


Financial merchant receives funding request via EFT 
switch, and verifies card number, expiration, and credit 
limit. 


9 


Funding is authorized by financial merchant 


10 


Funding is received by Wallet, which is an IPA (Internet 
Pay Anyone) account or DDA account. 



00427400.1 



-36- 



1 1 Funds are settled once a day between credit card's bank 
I and user's bank's IP A or PDA. 

Although the present invention has been described in relation to 
particular embodiments thereof, many other variations and other uses will be 
5 apparent to those skilled in the art. It is preferred, therefore, that the present 

invention be limited not by the specific disclosure herein, but only by the gist 
and scope of the disclosure. 
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We claim: 

1 . A method for effectuating an electronic payment between a payor 
and a payee, the payor having a payor account at a payor bank and the payee 
having a payee account at a payee bank, the method comprising the steps of: 

generating a payment request identifying the payee bank, the payee 
5 account and an amount of the payment; 

transmitting the payment request to the payor bank; 
debiting the payor account by the amount of the payment; 
transmitting a transaction instruction representing a credit in the amount 
of the payment from the payor bank, through an Automated Teller Machine 
1 o (ATM) system to the payee bank; and 

crediting the payee account in the amount of the payment in response to 
the receipt of the transaction instruction. 

2. The method as recited in claim 1, further comprising the step of 
retrieving payee information that identifies the payee bank and the payee 
account. 

3. The method as recited in claim 2, wherein the retrieving step further 
comprises the step of retrieving the payee information from an Internet web 
site. 

4. The method as recited in claim 3, wherein the retrieving step is 
automatic. 
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5. The method as recited in claim 1, wherein the step of transmitting 
the payment request to the payor bank further comprises the step of 
transmitting the payment request through the Internet. 

6. The method as recited in claim 5, wherein the step of transmitting 
the payment request to the payor bank is accomplished by using a personal 
computer. 

7. The method as recited in claim 5, wherein the step of transmitting 
the payment request to the payor bank is accomplished by using am Internet 
enabled ATM machine. 

8. The method as recited in claim 1, wherein the step of transmitting 
the payment request to the payor bank further comprises the step of 
transmitting the payment request by telephone. 

9. The method as recited in claim 1 , further comprising the step of 
transmitting a guarantee of the payment from the payor bank to the payee. 

10. The method as recited in claim 9, wherein the transmittal of the 
guarantee is directly to the payee. 

11. The method as recited in claim 9, wherein the transmittal of the 
guarantee is from the payor bank to the payor to the payee. 
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12. The method as recited in claim 9, further comprising the step of the 
payor bank digitally signing the guarantee. 

13. The method as recited in claim 1, wherein the payee account is a 
deposit only account. 

14. The method as recited in claim 1, wherein the payee is a billing 
company, the payor is a customer of the billing company and the payment is in 
response to a bill from the billing company. 

15. The method as recited in claim 14, further comprising the step of 
receiving the bill electronically. 

16. The method as recited in claim 15, wherein bill is electronically 
received via E-mail. 

17. The method as recited in claim 1 5, wherein bill is electronically 
received from an Internet site. 

1 8. The method as recited in claim 14, further comprising the step of 
receiving a template containing at least information identifying the payee bank 
and payee account . 

19. The method as recited in claim 1 8, further comprising the steps of: 
inserting into the template the amount of the payment; and 
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generating the payment request in response to the information 
contained in the template . 

20. A method for effectuating electronic payments for online purchases 
made by a consumer from a merchant, the method comprising the steps of: 

retrieving from an Internet site of the merchant a purchase amount and 
merchant information identifying a merchant's financial institution and a 
5 merchant's account; 

forming a payment request including the purchase amount and the 
merchant information; 

transmitting the payment request to a financial institution at which the 
consumer maintains an account; 
l o debiting the consumer's account by the purchase amount; 

generating a payment instruction for crediting the merchant's account 
by the purchase amount 

transmitting the payment instruction to the merchant's financial 
institution through an Automated Teller Machine (ATM); and 

crediting the merchant's account by the purchase amount. 

2 1 . The method as recited in claim 20, wherein the retrieving step is 
automatic. 

22. The method as recited in claim 20, wherein the step of transmitting 
the payment request to the consumer's financial institution further comprises 
the step of transmitting the payment request through the Internet. 
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23. The method as recited in claim 22, wherein the step of transmitting 
the payment request to the consumers's financial institution is accomplished by 
using a personal computer. 

24. The method as recited in claim 22, wherein the step of transmitting 
the payment request to the consumer's financial institution is accomplished by 
using am Internet enabled ATM machine. 

25. The method as recited in claim 20, wherein the step of transmitting 
the payment request to the consumer's financial institution further comprises 
the step of transmitting the payment request by telephone. 

26. The method as recited in claim 20, further comprising the steps of: 
generating a payment advice guaranteeing the payment amount will be 

credited to the merchant's account; and 

transmitting the payment advice to the merchant. 

27. The method as recited in claim 26, wherein the transmittal of the 
guarantee is directly to the merchant. 

28. The method as recited in claim 27, wherein the transmittal of the 
guarantee is made using a different Internet Protocol (IP) address from the IP 
address used by the consumer to view the merchant's Internet site. 
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29. The method as recited in claim 26, wherein the transmittal of the 
guarantee is from the consumer's financial institution to the consumer to the 
merchant. 

30. The method as recited in claim 26, further comprising the step of 
the payor bank digitally signing the guarantee. 

3 1 . The method as recited in claim 20, wherein the merchant's account 
is a deposit only account. 

32. The method as recited in claim 20, wherein the consumer's account 
is a demand deposit account. 

33. The method as recited in claim 20, wherein the consumer's account 
is an account only used for making payments using the method of the present 
invention. 

34. The method as recited in claim 20, wherein the consumer's account 
is funded from a different account maintained by the consumer. 

35. The method as recited in claim 34, wherein the different account is 
a demand deposit account. 
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ABSTRACT OF THE INVENTION 

A method for effectuating electronic payments more specifically for 
making electronic payments for Internet purchases. Upon finding an item 
which it wishes to purchase on an Internet retailer's web site, a consumer using 
its Internet software extracts from the web site a price quote for the proposed 
purchase along with an identification of the merchant's bank and account 
number. The customer transmits a payment request message to its own bank 
over the Internet. This payment request message simultaneously requests that 
the consumer's account be debited for the amount of the price quote and that 
the payment be made crediting the merchants account at the merchants bank. 
The consumer's bank generates a payment advice that guarantees the payment. 
The payment advice is transmitted to the merchant. With guaranteed funding, 
the merchant can immediately deliver the goods of services to the consumer. 
The customer's bank credits the merchant's account using the regional ATM 
network infrastructure. 
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